The present invention relates generally to a system and method for providing access to log data files, and more particularly but not exclusively to a system for tracking specific events in the log data files based on user-defined search criteria.
Computer software programs can be very lengthy and complex, often requiring teams of programmers to write the code. Due to the complexity and length of the program source code, one of the biggest challenges faced by programmers is debugging. Debugging is the process of identifying and correcting errors within a computer program to ensure the program behaves as expected. For some programming systems, when a computer program is executed, a program execution log data file is generated. The program log data file may include a description of the execution results from each execution. The log data file typically includes execution error messages and warnings. Computer programmers use this log data file to assist in the debugging process.
Each computer language has its own program log data file format, however for the purpose of illustration we will discuss SAS®. SAS® is a business intelligence and analytics software system that uses a proprietary programming language. Typically used at the enterprise level, SAS® provides an organization with the ability to data mine and subsequently process the mined data into useful analytic and statistical data to further long range and strategic planning. The following terms will be used when discussing SAS®. A SAS® system is the actual software designed by the SAS® institute. A SAS® Application Program is an application program that has been developed to run on the SAS® system. A SAS® Log File is the program log data file created upon execution of a SAS® application program.
Due to the large volume of data typically processed with a SAS® application program, the log data files produced can be very extensive. A source code program with one hundred lines of actual SAS® code could produce a SAS® log file containing over a million lines of output thus making reviewing the log data file manually an impractical if not impossible task for a programmer, or even a team of programmers.
An additional difficulty for programmers writing a SAS® application program is that unlike other languages such as C++, Visual Basic and COBOL, SAS® does not halt the execution of the program when an error is encountered within the code. For example, in many other programming languages, when a division by zero occurs in the program code, the program immediately halts execution and throws a run time error, alerting the programmer that an error has occurred. However, the SAS® system functions differently. During execution of a SAS® program having a divide by zero, a character is inserted to replace the division by zero so that the program can continue to execute. Of course, this insertion usually causes incorrect output results.
Similarly, the SAS® system may read corrupt and missing data files, again replacing the corrupt or missing data with a placeholder and continue to execute the program. The result of these inserted characters is that the output data is inaccurate. While some other programming languages may have stopped the program execution upon encountering such conditions, the SAS® system does not. This aspect of the SAS® system adds an extra burden on the programmer to ensure the output data is in fact correct.
In addition to unexpected output results, the fact that SAS® application programs may continue to execute even after encountering anomalies excessive CPU time has been spent to compile and execute the SAS® application program without addressing the anomaly. Because the SAS® system will not stop the execution of a program even when errors are encountered, CPU time is spent to fully execute programs that otherwise could have been halted upon encountering the error. Thus, executing a SAS® application program that contains errors is a potential waste of CPU time and can be very costly to an organization.
As noted above, when a SAS® application program is executed with errors the output report may contain inaccurate data results. An organization may be using the data results in order to make important decisions. Inaccurate data, in this situation, could be disastrous.
At the present time, in order to ensure proper data output results the programmer has to manually review the SAS® log to debug the program code. The amount of time and effort required to completely and accurately interrogate the data for critical status events is prohibitive. Also, the assessment of these events is often incomplete or inaccurate often creating conditions whereby the integrity of the program results are compromised or repetitive programming is required to completely eliminate all negative status events thereby increasing the overall development cycle times and associated costs. Programmers, just like CPU time, are expensive resources. For a programmer to spend hours reviewing a SAS® log in order to correct errors instead of developing new code can be extremely inefficient.
There have been previous attempts to address the above-discussed problems. In the paper entitled “% LOGCHECK a Convenient Tool for Checking Multiple Log Files” by Suzanne Humphreys (Retrieved Jul. 29, 2009 from http*//www*lexjansen*com/pharmasug/2008/cc/cc02*pdf)1, Humphreys presents a tool (LOGCHECK) for checking multiple log files and producing a summary report of the findings. LOGCHECK is a macro that can be used directly within the SAS® system. Another log checking utility program called Check Log is detailed in the paper entitled “A Utility Program for Checking SAS® Log Files” by Carey G. Smoak (Retrieved Jul. 29, 2009 from http*//www2*sas*com/proceedings/sugi27/p096-27*pdf.) The Check log program scans one or more SAS® log files for errors and warnings and then allows the user to print out a report of the findings. In the paper entitled “SAS® Log Summarizer—Finding what's most Important in the SAS® Log”, (Retrieved Jul. 29, 2009 from http*//analytics*ncsu*edu/sesug/2008/CC-037*pdf) Milorad Stojanovic discloses a method similar to that of both Humphreys and Smoak. Stojanovic parses the SAS® log file in order to search for three keywords, ERROR, WARNING and NOTE. The ultimate goal of Stojanovic's program is to put the SAS® log messages into a hierarchy from severe to simply informative. 1 In conformity with 37 CFR 1.57(d) which prohibits use of executable hyperlinks in patent documents, this document uses asterisks in lieu of periods in example hyperlinks. In actual practice, these asterisks would, of course, be periods
While all of the aforementioned programs allow a user access to a report that highlights errors and warnings, they do not provide the user with interactive access to the log data file. Being able to interact with the log data file would provide a user focused and efficient access to the log data file saving time during the debugging process.
From the foregoing it will be apparent that there is still a need for a system and method to provide access to log data files and to provide a system that gives users real-time access to run time errors and warnings.